Most computer applications (hereinafter “applications”) are very complex systems that, due to their complexity, require significant testing to ensure that the application will execute as desired.
To facilitate the testing of applications, test cases or test suites (essentially a collection of test cases) are designed, implemented and used to test a portion or the whole of an application (often referred to as the subject under test). In many applications, these test cases manipulate the external facade or interface of the subject under test. The results of these test cases are then analyzed and evaluated. As many applications are quite complex, several, sometimes hundreds, of test cases are used for the testing of a single application.
For example, a database application may need to be tested to determine whether data can be added to the database (this is the test case). A test script would need to be created to implement the test case. The exemplary test script could include several steps, instructions or processes to test this aspect of the application including: gaining access to update the database, transmitting the update request; receiving confirmation that the update request has been executed; reading from the database to determine if the data in the update request was stored successfully; and then logging off from the database.
The processes or steps within a test script are executed linearly. Interspersed amongst these steps are one or more verification points which are designed to gather data representative of the operation of the subject under test. A verification point, when inserted into the test script, will issue or output a binary value (usually a single bit of data—e.g., a boolean value) that indicates whether a step(s) with which the verification point is associated was successfully or unsuccessfully completed. The output of the test script execution, which includes the values output by the verification points, is typically stored in a test case execution log.
The verification points also enable testers to analyze the test case execution log to ascertain which processes in the test case failed and, thus, which portions of the subject under test need to be investigated to rectify any problems (i.e., solve any bugs in the application, if necessary).
If a tester desires to vary the linearity of the execution model associated with the test script, then the test script is exposed by the testing tool and the tester manually modifies the test script (using, typically, a language proprietary to the testing tool being used). Unfortunately, this type of modification is not usually further supported by the testing tool. That is, the testing tool will execute the modifications and provide a mechanism to run and modify the test script, but the test tool does not provide any advanced tools which operate in conjunction with the modifications.
As a consequence of the ability to make manual modifications, many advanced testers use testing tools to create only a skeleton of a test script and add the “guts” or substance of the test script manually. This type of use leads to considerable costs for maintaining the test scripts.
Some testing tools presently on the market will terminate the execution of a test script as soon as a single verification point is reached which indicates that an associated step was not performed successfully. Other testing tools will attempt, if possible, to continue processing the test script execution and outputting data from the verification points.
As a result of the data output by the verification points, a test script execution will generate an output which indicates whether the application successfully or unsuccessfully performed the test case (the test output). The test output of the test script execution (which is in addition to test logs that are typically generated) is, like the output of a verification point, a binary value. If even a single step in the test script failed then the entire test script execution will output a value also indicating failure of the execution of test script (i.e., the application failed in performing the test case). Only when all steps are successfully performed will the test script output indicate successful completion.
It will be appreciated that when a deadline for release of an important application draws near, the application developers (the development team) are under considerable stress to have the application ready for release with a minimum number of bugs or quality or stability related issues. At this time, review of the test output data generated by the test scripts executions is often at its highest. During this review, much effort and time is spent attempting to ascertain the reason certain test script execution has failed to complete successfully indicating a likely problem with the subject under test. It is common in the industry, especially as deadlines loom, to disregard the test results from some test scripts execution for a variety of reasons. For example, a test script may be considered by the development team as testing an “unimportant” or “inconsequential” aspect of the subject under test. Other test scripts may be disregarded on an ad hoc basis because of a developer's intuition or experience indicating that the unsuccessful result from the execution of a test script was not as a result of a failure of the subject under test but rather another application or component (e.g., the operating system, memory management, etc.). Unfortunately, this analysis is often inaccurate or misguided and potentially results in the release of an unacceptable application. Moreover, the rationale for ignoring some test results while relying on others is not documented which may prove unfortunate after a product has been released.
In a further shortcoming of known systems, significant time may be spent analyzing the unsuccessful results issued by a test script execution in an attempt to ascertain the cause(s) of the failure. This analysis is premised on the possibility that all failures should be determined and that most or sometimes all of the failures are the result of flaws or bugs in the subject under test. However, in some instances, the failure may be the result of a failure in another portion of the computer system(s) on which the subject under test is relying. In such an instance, a developer or tester may have misspent significant time and energy investigating a flaw which is not caused by the subject under test.
For example, returning to the database example described above, suppose that the test script process for logging off from the database required transmitting to the database a “logoff” command. Further assume that the database itself (and not the application/subject under test) had a slight bug that issued an error message despite properly logging off a user. In this scenario, the verification point associated with the portion of the test script for logging off would output indication of a failure and the test script, even if every other process completed successfully, would, as a result of the reported logoff failure, also generate test output indicating a failure of the subject under test. Moreover, while this failing result may be technically accurate (i.e., the test script did not successfully complete each of the processes contained therein) it is misleading and inaccurate in substance (i.e., the subject under test actually successfully performed all of its processes and only another element relied upon by the subject under test failed). This situation could lead to significant time and energy being spent by a developer attempting to eradicate a bug in the subject under test which does not exist (the bug exists in the database).
Since a test script may incorporate several (sometimes hundreds) of verification points, much effort needs to be expended to determine a source of a failure reported by a test script. In many circumstances, once the verification point reporting a failure which contributed (in whole or in part) to the failure of a test script is identified, a developer or tester may decide that the identified verification point can be disregarded. This information is often not passed on to other developers or testers which often results in other developers or testers wasting time performing identifying the verification point and then reaching the same conclusion to disregard the results. In other circumstances, a decision reached by a developer to disregard one or more verification points in a test script is made without significant thought or consideration and the resulting decision to disregard is flawed or faulty. Alternatively, one developer may conclude that results from a particular verification point can be disregarded while a different developer reaches a different conclusion. As a result of this types of situations, present test scripts and testing methodologies have significant shortcomings.
Accordingly, a testing measurement which addresses, at least in part, some of the shortcomings described above is desired.